Many organizations are becoming more involved in conducting business electronically (so called e-business), over the Internet, or on other computer networks. E-business calls for specialized applications software such as Electronic Bill Presentment and Payment (EBPP) and Electronic Statement Presentment applications. To implement such applications, traditional paper documents have to be converted to electronic form to be processed electronically and exchanged over the Internet, or otherwise, with customers, suppliers, or others. The paper documents will typically be re-formatted to be presented electronically using Hypertext Markup Language (HTML) Web pages, e-mail messages, Extensible Markup Language (XML) messages, or other electronic formats suitable for electronic exchange, processing, display and/or printing.
Billers who provide their customers with the option of viewing and paying their bills over the Internet have varying requirements for the business content to be provided. In addition to varying content, different billers will want the customer interface and presentation of the billing information to have a particular “look-and-feel.”
Instead of programming their own EBPP system from scratch, billers have the option of purchasing or outsourcing a pre-made EBPP system from a vendor. The biller may also hire a third party electronic billing service to provide the desired EBPP services to the biller's customers. In any of these situations, a pre-made EBPP system must be customized to meet the particular business and presentation requirements of the biller. Accordingly, a vendor who provides an EBPP solution to multiple billers needs to consider the extent to which its system can be customized, and the ease with which customization can be achieved.
FIG. 1 depicts a prior art EBPP system. In the prior art system, for one or more billers, EBPP computer system 10 controls the presentment of billing service web pages 40 over the Internet 2 to customer 1. Billing information is gathered by EBPP computer system 10 from the biller's legacy computer systems 20. Typically, billing data will be parsed by EBPP system 10 from a print stream generated by the legacy system 20, the legacy print stream being originally intended for printing conventional hard-copy bills. A preferred method for parsing billing data from the legacy print stream is described in co-pending patent application Ser. No. 09/502,314, titled Data Parsing System for Use in Electronic Commerce, filed Feb. 11, 2000, which is hereby incorporated by reference into this application.
In addition to communication via web pages 40 generated during a session, EBPP computer system 10 includes the capability of sending and receiving e-mail messages 50 to and from the user 1. Typically, system 10 will generate a message to user 1 upon the occurrence of a predetermined event. An example of such an event is a new billing statement becoming available, or the approach of a due date for an unpaid bill. EBPP system 10 is also capable of communicating with a bank or ACH network 30 to process bill payment activities.
System 10 includes a data repository 11 in which billing data for use with system 10 may be stored in a variety of formats. Data in the repository can be organized in a database, such as the kind available from Oracle or DB2. Statement data archives may also be stored in a compressed XML format. XML is a format that allows users to define data tags for the information being stored.
The EBPP computer system 10 itself is typically comprised of standard computer hardware capable of processing and storing high volumes of data, preferably utilizing a J2EE platform. EBPP system 10 is also capable Internet and network communications. Of interest with respect to the present patent application, the prior art EBPP computer system 10 includes a software architecture within an application server 12 for generating and handling electronic billing functions. At a fundamental level, the software architecture of the prior art system 10 is split into two conceptual components, the front-end presentation logic 13 and the back end servicing logic 14. The split between front-end and back-end logic 13 and 14 serves to reduce the amount of recoding necessary for the system to be customized for different billers.
The front-end presentation logic 13 is the portion of the software that is the primary Internet interface for generating web page presentations. As such, the front end presentation logic 13 includes code that is custom written to meet the specific business and presentation needs of the biller. Functionality that might be included in front-end logic 13 is enrollment, presentation, payment instructions, and reporting.
Typically, front-end logic 13 is comprised of Java Server Pages (JSP's) that control the presentation of billing information in the form of web pages. The front-end logic JSP's also receive and respond to inputs as the customer makes requests for various services to be provided. The JSP's can be recoded to accommodate different look-and-feel and business requirements of different billers. Within the JSP's, front-end logic 13 can also utilize Enterprise Java Beans (EJB's) that comprise objects for performing specific tasks.
The back-end services logic 14 comprises the software for functions that typically do not need to be customized for particular billers. Preferably, very little of the back-end services must be customized for a particular biller's needs. For example, back-end logic may include the software for extracting the billing data from the biller legacy billing computers 20. Similarly, logic for handling of payments with the bank or ACH network 30 and systems for generating and receiving e-mail messages will be handled in the back-end services logic 14.
As a result of the distinction between the front-end and back-end logic 13 and 14, re-coding of software to provide customization for different billers is somewhat reduced. However, a significant amount of presentation logic and some business logic must always re-written to meet a particular biller's needs. The re-coding required for customization can require a high degree of programming skill and can add expense to implementation of a biller's on-line presence. The requirement for re-writing code introduces a risk that changes to the way that a web page looks may in fact introduce a problem that could cause the content of the information being displayed to be incorrect. Another problem with this prior art system is that after a system is customized it may be difficult to provide upgrades and future releases of the software. In order to be sure that new releases work properly substantial efforts would be necessary to retrofit the new release with the code changes that were made for the particular biller.
In the prior art EBPP system 10, back end logic 14 or front end logic 13 may also include software agents that perform periodic tasks without prompting from an end-user 1. For example, the system 10 may monitor for the presence of new billing information available to be loaded. Upon detecting the presence of new billing information, a software agent runs a job to load the new information based on parameters programmed into the software agent.
As with other aspects of the front and back end logic 13 and 14, the ability to customize the software agents is an important consideration in enabling a system used to service multiple billers. If a biller wanted an agent to run a document loading job based on different parameters than another biller, then those varying parameters may require recoding or reprogramming of logic. Similarly, a biller may only want to use some available software agents, but not others, in providing EBPP services. Software agents that are important to one biller, may be of little interest to another. Thus the concerns about customization and upgradeability discussed above, are just as important for the software agent portions of the EBPP systems.
In the prior art, certain Internet services such as “Yahoo!” and “Excite” have allowed registered users to create personalized web pages. Such personalized web pages allow the user to select certain information and presentations of the information available from the service. When the registered user visits the web site and is recognized, the user's selected information and arrangement is displayed. For example, the user may choose to see an arrangement including a weather report for his region, sports scores for his favorite teams, and stock quotes for his investment portfolio. These personalization features, however, do not provide a way for a biller to offer EBPP services customized to its particular business and presentation needs. Further, these personalization features do not include capability for customization of software agents that perform tasks to operate the an EBPP system.
Accordingly, the prior art leaves disadvantages and needs to be addressed by the present invention, as discussed below.